그림으로 배우는 HTTP & Network basic 2

네트워크 인증

Basic 인증

  • 특징

    1. Base64 인코딩 형식을 사용하고 있지만, 암호화가 아니기 때문에 누구나 복호화 할 수 있다.
  • 인증 절차

    1. Basic 인증이 필요한 리소스에 리퀘스트가 있을 경우 서버는 상태코드 401 Authorization Required와 함께 인증의 방식(Basic)과 Request-URI의 보호 공간을 식별하기 위한 문자열(Realm)을 WWW-Authenticate 헤더필드에 포함해서 응답을 반환한다.
    2. ID:PW 형태로 Base64 인코딩을 진행하고, 이 문자열을 Authrization 헤더에 포함해서 리퀘스트를 송신.
    3. Authorization 헤더 필드를 포함한 리퀘스트를 수신한 서버는 인증 정보가 정확한지 여부를 판단한다. 그리고 정확하면 Request-URI 리소스를 포함한 리스폰스를 반환한다.

Digest 인증

  • 특징

    1. 챌린지 리스폰스 방식은 최오세 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산한다. 이 값을 상대에게 송신하여 인증을 하는 방법이다.
    2. 패스워드의 도청을 방지하기 위한 보호기능은 제공하지만 위장 방지 기능은 제공하지 않는다.
    3. 하지만 basic 인증과 비슷하게 문제가 많기 때문에 사용하지 않는다.
  • 인증 절차

    1. 인증이 필요한 리소스에 리퀘스트가 있을 경우 상태코드 401 Authorization Required와 함께 챌린지 리스폰스 방식의 인증에 필요한 챌린지 코드(nonce : 리스폰스 반환시 생성되는 유일한 문자열)를 WWW-Authenticate 헤더필드에 포함해서 리스폰스를 반환한다.
    2. Authorization 헤더필드를 포함한 리퀘스트를 받은 서버는 인증 정보가 정확한지 판단한 후에 응답한다.

SSL Client 인증

  • 특징

    1. 위장의 대책으로 사용된다.
    2. 단독으로 사용하지 않고 폼베이스를 이용하여 사용한다. 즉 첫 번째 인증 정보로 SSL 클라이언트 인증을 하여 클라이언트의 컴퓨터를 인증하고 다른 인증정보인 패스워드를 사용하여 유저의 본인 확인을 한다.
    3. 하지만 인증 기관에서 클라잉너트 증명서를 구입해야 하고 가격이 비싸다.
  • 인증 절차

    1. 인증이 필요한 리소스의 리퀘스트가 있었을 경우 서버는 클라이언트에게 클라이언트 증명서를 요구하는 “Certificate Request” 라는 메시지를 반환한다.
    2. 유저는 클라이언트 ㅈ으명서를 Client Certificate라는 메시지로 송신한다.
    3. 서버는 클라이언트 증명서를 검증하여 검증 결과가 정확하다면 클라이언트의 공개키를 취득한다.

폼 베이스 인증

  • 특징

    1. 클라이언트가 서버 상의 웹 어플리케이션에 자격 정보(Credential)를 송신하여 그 자격 정보의 검증 결과에 따라 인증을 하는 방식이다.
    2. 클라이언트 증명서는 비용이 많이 들고 웹사이트의 인증 기능으로서 요구되는 표준이 없기 대문에 웹 어플리케이션은 제각각의 폼 베이스 인증을 사용한다.
    3. HTTP는 stateless 프로토콜이기 때문에 방금 전에 인증을 성공 했던 유저라는 상태를 프로토콜레벨에서 유지할 수없기 대문에 세션관리와 쿠키를 사용하여 상태 관리를 보충한다.
    4. 패스워드를 안전하게 저장하기 위해 salt라는 부가정보를 사용하여 해시라는 알고리즘으로 계산한 값을 저장한다.
  • 인증 절차

    1. https를 사용하여 인증 정보(아이디 비번)을 전송한다.
    2. 정보가 검증되면 서버는 세션 아이디를 발행하고, 저장 후 세션을 받아 클라이언트로 전송한다.
    3. 서버측에서 세션 ID를 받은 클라이언트는 쿠키로 저장하고 매 요청마다 세션을 포함하여 요청을 보낸다.

http에 기능을 추가한 프로토콜

http는 HTML로 작성된 문서를 전송하기 위한 프로토콜 HTTP 이다.

HTTP에 많은 기능이 추가됬음에도 불구하고 아직도 기본으로 하는 이유

  • 기업이나 조직에 방화벽에는 기본 기능으로 http 포트만 저장이 되있으므로 새로운 프로토콜을 넣으면 모두 변경해야 하기때문에 새로 만들기에는 무리가 있다.
  • HTTP 클라이언트인 브라우저가 보급되어 있는 것이나 HTTP 서버가 많이 보급되고 있는 것 등의 이유도 있다.

HTTP의 병목이 생기는 이유

  • 1개의 커넥션으로 1개의 리퀘스트만 받을 수 있다.
  • 리퀘스트는 클라이언트에서만 시작할 수 있다. 리스폰스만 받는 것은 불가능하다.
  • 리퀘스트/리스폰스 헤더를 압축하지 않은 체로 보낸다. 헤더의 정보가 많을 수록 지연이 심해진다.
  • 장황한 헤더를 보낸다. 매번 같은 헤더를 보내는 것은 낭비다.
  • 데이터 압축을 임의로 선택할 수 있다. 강제적이지 않다.

병목 현상 해결 방법

  1. Ajax(Asynchronous JavaScript+XML)

    • JavaScript나 DOM(Document Object Model) 조작 등을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다.
    • 페이지의 일부분만 갱신되기 때문에 리스폰스로 전송되는 데이터 양은 줄어든다.
    • Ajax의 핵심 기술은 XMLHttpRequest라는 API로 JavaScript등의 스크립트 언어로 서버와 HTTP 통신을 할 수 잇다.
  2. Comet

    • 서버 측의 컨텐츠에 갱신이 있었을 경우 클라이언트로 부터 요청을 기다리지 않고 클라이언트에게 보내기 위한 방법이다.
    • 응답을 연장함으로써, 서버에 통신을 개시하는 서버 푸시 기능을 유사하게 따르고 잇다.
    • 리스폰스를 보류하기 위해 커넥션 시간이 길어지고 리소스를 낭비한다.
  3. SPDY

    • TCP/IP의 어플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다.
    • SPDY가 세션계층으로서 그 사이에 들어감으로써 데이터의 흐름을 제어하지만, HTTP의 커넥션은 확립되어 있다.
    • SPDY는 기본적으로 한 개의 도메인(IP 주소)과의 통신을 다중화할 뿐이기 때문에 하나의 웹사이트에서 복수의 도메인으로 리소스를 사용하고 있는 경우에는 효과가 한정적이다.
    • 기능

      1. 다중화 스트림 : 단일 TCP 접속을 통해 복수의 http 리퀘스트를 무제한으로 처리할 수 있다.
      2. 리퀘스트의 우선 순위 부여 : 각 리퀘스트에 우선 순위를 할당할 수 잇다. 대역폭이 좁으면 처리가 늦어지는 현상을 해결하기 위한 것이다.
      3. HTTP 헤더 압축
      4. 서버 푸시 기능
      5. 서버 힌트 기능

브라우저에서 양방향 통신을 하는 WebSocket

  • 기능

    1. 서버 푸시
    2. 통신량 삭감 : HTTP에 비해 자주 접속을 하는 오버헤드가 적고, 헤더의 사이즈도 작다.
  • 핸드쉐이크/리퀘스트

    1. Upgrade 헤더에 websocket 를 붙혀 핸드쉐이크를 한다. Sec-WebSocket-Key에는 핸드 쉐이크에 필요한 키가 저장되어 SetWebSocket-Protocold에는 사용하는 서브 프로토콜이 저장되어져 있다.
    2. 응답시에는 101 상태 코드로 반환되며 Set-WebSocket-Accept는 Sec-WebSocket의 값에서 생성된 값이 저장된다.
    3. 핸드쉐이크 후에는 HTTP가 아닌 WebSocket 독자적인 데이터 프레임을 이용해 통신한다.

컨텐츠에서 사용하는 기술

HTML

  • HTML(Hyper Text Markup Language) 웹 상에서 하이퍼텍스트(Hyper Text)를 보내기 위해 개발된 언어이다. 하이퍼텍스트는 문서 시스템의 하나로서, 문서 중에 임의의 장소의 정보가 다른 정보(문서나 이미지 등)에 관련된 즉 링크되어 있는 문서이다.
  • 디자인을 적용하는 CSS(Cascading Style Sheets)는 HTML 각 요소를 어떻게 표시할지를 지시하는 것으로, 스타일 시트라고 불리는 사양중 하나이다. CSS는 문서의 구조와 디자인을 분리한다는 이념에서 만들어 졌다.

Dynamic HTML

정적인 HTML 내용을 클라이언트 사이드 스크립트를 사용해서 동적으로 변경하는 기술을 말한다. HTML등으로 만들어진 웹 페이지를 JS등의 클라이언트 사이드 스크립트로 조작하여 동적으로 변화시킨다.

DOM(Document Object Model) :HTML 문서와 XML 문서를 위한 API이다. Dom을 사용하면 HTML 내의 요소를 오브젝트로 다룰 수 있기 때문에 요소 내의 문자열을 추출하거나 CSS를 프로퍼티로서 변경해 디자인알 수 있다.

웹 어플리케이션

웹 어플리케이션은 웹 기능을 사용해서 제공되는 프로그램을 지칭한다. 어플리케이션이 발달하면서 프로그램에 의해 생성된 컨텐를 만들어 보낸다. 이것을 동적 컨텐츠라 하고, 사전에 준비된 컨텐츠를 동적 컨텐츠라고 한다.

  1. CGI(Common Gateway Interace) : 는 웹 서버가 클라이언트에서 받은 리퀘스트를 프로그램에 전달하기 위한 구조이다.

    • 특징

      1. 매 요청마다 프로세스를 실행하기 때문에 대량 접속시 문제가 될 수 있다.
  2. java Servlet

    • 설명 : 서버상에 HTML등의 동적 컨텐츠를 생성하기 위한 프로그램이다. java 프로그래밍 언어의 사양의 하나이다.
    • 특징 : 웹서버와 같은 프로세스(컨테이너) 속에서 동작하기 때문에 비교적 부하를 적게 하여 동작시킬 수 있다.

데이터 통신에 이용되는 포맷이나 언어

  1. XML(eXtensible Markup Language) : 목적에 맞게 확장 가능한 범용적으로 사용할 수 있는 마크업 언어이다. HTML과 같은 문서 기술 언어이다. 하지만 HTML에 비해 데이터를 기술하는 것에 특화되어 있다.

    • 특징

      1. XML 구조는 트리 구조로 되어져 있다
      2. XML 구조는 태그로 나뉘어져 있고 트리 구조로 되어 있기 때문에 XML 구조를 해석하고 요소를 뽑아내는 파서 기능에 의해 데이터 추출을 쉽게할 수 있다.
  2. RSS/ATOM

    • 설명 : 뉴스나 블로그의 기사 등의 갱신 정보를 송신하기 위한 문서 포맷의 총칭으로 둘다 XML을 이용한다.

JSON(JavaScript Objsct Notation)

경량 데이터 기술 언어로서 JavaScript에 있어서 오브젝트 표기법을 바탕으로 하고 있다. 데이터 형은 boolean null 오브젝트 수치 문자열 등 7가지 이다.

WebSocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격이다. 한번 접속을 확립하면 그 뒤의 통신은 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML 이나 이미지 등 임의 형식의 데이터를 보낸다.


Written by@Zero1
This blog is for that I organize what I study and my thinking, feeling and experience.

GitHub